NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/dcom/modems-part1/9639

Internet Message Format | 1996-08-05 | 5.2 KB

Path: news.primenet.com!not-for-mail
From: [e-mail] (Bob Nixon)
Newsgroups: comp.dcom.modems
Subject: Re: Is USR going to support 42bis+ on future courier upgrades?
Date: 29 Mar 1996 17:43:01 -0700
Organization: primenet.com
Sender: [e-mail]
Message-ID: <4ji02l$[e-mail]>
References: <4j2fv1$[e-mail]> <4j2iun$[e-mail]> <4j3r1f$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Posted-By: ip21-078.phx.primenet.com
X-Newsreader: WinVN 0.99.2

No HS link, This was all TCP/IP(PPP) with two occurances of WS-FTP32 set
to the same place(my home directory at my internet provider). Send the
file in, rename it then send it back and as quick as I can click the mouse
key send the original "IN" back in too. Same file transfering in oposite
directions except that one has been renamed. This is actually a little
slower than your proposed HS-Link or s-modem due to greater TCPIP
overhead, reliance on the hosts buffering and disk access load and finally
and probably the least significant is my own computers disk buffering of
the two files. This was also done during my ISP's peak load time or about
9:30PM on a week night.

You've also IMO been reading too much negitive crap about WIN-95.
Althought it strickly speaking loads the DOS 7 kernel in first according
to MS anyway, the code loaded after that is 32bit. The DOS 7 kernel is
retained for backward compatibility.



In article <[e-mail]>,
[e-mail] says...
>
>On Tue, 26 Mar 1996, Bob Nixon wrote:
>
>> Appology accepted, I admittedly don't understand the inner workings of
how
>> Win-95 handles the com ports or if the DTE settings above 115200 are
real
>> but concerning the mutitasking while moving files both in and out plus
>> Bi-directional transfers here are my nunbers for single and
by-directional
>> transfers of highly compressable files while running a DOS graphics
based
>> game running in demo mode in the background. My system is AMD486DX4-120
>> w/32megs of ram and Diamonds Stealth-32 graphics card. The modem is USR
>> Courier with V.34+ code. Tranfers for single or one way file transfer
of a
>> Coreldraw.cdr(border file) 10600cps both inbound and outbound with a
>> 28800/28800 connection. Bidirections transfer slowed to about 8000cps
on
>> each direction. Both these numbers are nearly identical to the speeds
that
>> I've gotten on previous tests. BTW transfer method was WS-FTP32 with a
>> Win-95 ppp connection to my ISP, Primenet in Phoenix, AZ at 9:30PM(busy
>> prime hours) to my home directory.
>>
>> PS. Comm overruns were not observed during any testing.
>
>Ok, let me try to explain what's going on here. First, the modems between
>the computers are controlling the transfer in conjunction with the CPU's
>at each end. In addition, the 115200 DTE rate is bottle-necked down to
>28800 between the modems. This is true even though the throughput rate is
>above 10600 cps. Why? you might ask. Well, the modems compress the data
>first *before* sending it. This also helps explain why the throughput
>in each direction drops when doing bi-directional transfers on
>uncompressed files; the modems each are doing double-duty compressing and
>uncompressing each data stream.
>
>Your numbers pretty much match mine on modem to modem transfers both in
>uni-directional and bi-directional transfers. I presume you used HS/Link
>for the bi-directional (and, from the rates on uni-directional, probably
>on those also)? I need to try this with Smodem (in my opinion, a more
>efficient and fault-free bi-directional protocol) and see what I get on a
>bi-directional transfer with that.
>
>Now, if you have two computers, hook up a null modem cable between them
>and open each port at 115200. Take a file and transfer it. That was my
>bench test for comparison between the linux and DOS platforms. No modems,
>no LapLink, just two comm programs (Commo on one side and minicom on the
>other) using zmodem (DSZ at one end, the built-in zmodem at the other)
>I would be interested to see results of a 230k port setting at each end
>with DOS or Win95 at each end also.
>
>The tests were made in one direction only; from the DOS box to the
>linux/DOS box, with the linux/DOS box booted to DOS and then booted to
>linux. When the linux/DOS box was in DOS, the comm program was Commo
>w/DSZ as the zmodem protocol drive (also did it with DSZ as a
standalone).
>
>Again, I am not using Win95 but I do know a little about that platform.
>It isn't really a true operating system, it runs on DOS 7.0 so it's
>subject to similar problems that any DOS box might have. It is, I am
>informed, much improved over Windows 3.1 (and WFWG 3.11) but I still see
>complaints about throughput and overruns.
>
>What amazed me about linux was the absolute lack of errors during a true
>hi-speed transfer (115200 from end to end). I was used to limiting the
>DOS-to-DOS connections to 57600 in order to limit the errors during
transfer.
>